Firewall Basics

In this guided exercise, you will apply what you have learned so far to configure an iptables firewall. You will use your findings to answer the questions on the Tasks tab.

You will begin by reviewing the current rulesets.

1. On the dock at the bottom of the screen, click the Terminal Emulator icon to open a Terminal window.
   
2. In the terminal window, type sudo iptables -L and press Enter to list the current policy chains (or rulesets).
   

   

   The output shown above tells us that the three chains (INPUT, FORWARD, and OUTPUT) are all using the default policy ACCEPT and have no other rules. In essence, the firewall is allowing all traffic in and out.
   
   Do you recall what we said about there always being a default policy (DROP ALL) at the bottom of every firewall ruleset? Well, meet the exception to that rule. After every rule is examined in the chain, the default will be to allow that traffic in iptables.
   
   Note: On a secure system with direct console access, the default policy can be set to default DENY, but you have to be very careful using a policy like this on a remote system or you can easily lock yourself out of the remote system completely.
   
   Let's create a fictional network we can use to test the iptables firewall. Let's say the remote lab system is both a web and an FTP server and there are two client systems on our network:  admin (10.0.0.1) and user (10.0.0.2). We want to allow admin SSH access to the remote lab system, but not allow anyone else SSH access. We want to allow HTTP access to everyone on the 10.0.0.0/24 network, but only allow FTP access to the user system. Our iptables ruleset would look like this:
   

   

   Note: This is not iptables syntax. We will get into that next.
   
3. At the prompt, type sudo iptables -A INPUT -s 10.0.0.1 -p tcp --dport 22 -j ACCEPT and press Enter to configure the first new rule.
   

   

   Here is the command syntax breakdown:
   
   -A - Append
   INPUT - to the INPUT Chain
   -s - from Source IP
   -p - to Protocol
   --dport - to Destination Port
   -j - Jump (stop processing rules and take action)
   ACCEPT - Allow this traffic
   
4. At the prompt, type sudo iptables -L and press Enter to display the updated rules.
   

   

   The iptables firewall will accept TCP traffic from ip 10.0.0.1 (ip-10.0.0.1.ec2.internal is a generated DNS name) destined for anywhere, as long as the port is 22 (SSH). We could have specified a destination instead of leaving it as “anywhere”, but this rule meets our needs. What will happen if the iptables firewall receives a packet that does not match this rule? As the default input policy is ACCEPT, that packet will be allowed.
   
   So far this is not much of a firewall - let's fix that.
   
5. At the prompt, type sudo iptables -A INPUT -s 10.0.0.0/24 -p tcp --dport 22  -j DROP and press Enter to configure the second new rule.
   

   

6. At the prompt, type sudo iptables -L and press Enter to display the updated rules.
   

   

   The second rule we just created will drop any traffic sent to TCP port 22 from the 10.0.0.0 network. Thus only 10.0.0.1 will be able to SSH to the remote lab desktop. For example, 10.0.0.2 would not have SSH access. We will prove this shortly.
   
7. Execute the following commands to add two additional rules to iptables, then execute sudo iptables -L to display the updated rules.
   
   sudo iptables -A INPUT -s 10.0.0.2 -p tcp --dport 21 -j ACCEPT
   
   sudo iptables -A INPUT -s 10.0.0.0/24 -p tcp --dport 21  -j DROP
   

   

   The rules now allow 10.0.0.1 to use SSH and 10.0.0.2 to use port 21 (FTP). Just as the firewall will drop any other traffic from the 10.0.0.0 network to port 22 (SSH), the firewall will drop any FTP traffic not coming from 10.0.0.2.
   
8. Execute the following commands to add two additional rules to iptables, then execute sudo iptables -L to display the updated rules.
   
   sudo iptables -A INPUT -s 10.0.0.0/24 -p tcp --dport 80 -j ACCEPT
   
   sudo iptables -A INPUT -s 10.0.0.0/24  -j DROP
   

   

   The rules now allow the entire 10.0.0.0 network to access port 80 (HTTP). That means both 10.0.0.1 and 10.0.0.2 have HTTP access. The last rule drops any other traffic from the 10.0.0.0 network. At last, we have a proper firewall. Now any traffic not allowed in the ruleset will be blocked.
   
   Based on the rules, here is the access we should be able to confirm:
   
   Admin (10.0.0.1) - TCP 22, 80
   User (10.0.0.2) - TCP 21, 80
   
   To test the firewall, we will use a tool called Mininet to emulate the admin and user desktops. We will use Nmap from these simulated desktops to validate iptables firewall.
   
9. At the prompt, type sudo ip addr add 10.10.10.10/24 dev eth0 and press Enter to create a “firewall” IP address for testing.
   
10. At the command prompt, type xhost + and press Enter to allow the simulated hosts to open x-terminals on the lab desktop.
    
    The simulated desktops are accessed using x-terminals (xterm).
    
11. At the prompt, type clabnet and press Enter to launch the default mininet simulator.
    
    By default, mininet creates two simulated desktops we can use for testing: h1 and h2.
    
12. At the mininet > prompt, type xterm h1 h2 and press Enter to open terminals for the simulated desktops.
    
    Two black x-terminal terminal windows will open.
    
    Keep the terminal window with Mininet running open for the rest of the lab. You can minimize the open terminal window or move it out of the way, just do not close it.
    
13. Position the h1 desktop window above the h2 desktop window so you can work in both x-terminal windows, then minimize the terminal window.
    

    

    Remember, the h1 window is 10.0.0.1 (admin) and the h2 window is 10.0.0.2 (user). The IPs given to h1 and h2 are the defaults used by Mininet. You can confirm this by typing ip a and pressing Enter in both x-terminal windows if you like.
    
14. On the dock at the bottom of the screen, click the Terminal Emulator icon twice to open two new Terminal windows, then place one above the other, resizing as needed.
    
    When finished, your desktop should look similar to the image below (two x-terminal windows and two terminal windows):
    

    

    You will run the next commands using the regular terminal windows you just opened. Don’t run any commands in the black x-terminal windows just yet.
    
15. In the top terminal window, type sudo nc -klvp 21 and press Enter to simulate an FTP server.
    

    

16. In the bottom terminal window, type sudo nc -klvp 80 and press Enter to simulate an HTTP server.
    

    

    The remaining commands will all be done in the black x-terminal windows.
    
17. In the top x-terminal window, type nmap -sT 10.10.10.10 and press Enter to scan the "firewall" IP we configured earlier. Note the output from the Nmap command.
    

    

    The iptables firewall is allowing the admin desktop access to SSH (TCP 22) and HTTP (TCP 80), but does not allow access to the FTP port. No other ports are open or allowed thanks to the DROP ALL rule we added to the bottom of the INPUT chain.
    
18. In the bottom x-terminal window, type nmap -sT 10.10.10.10 and press Enter to scan the IP we configured earlier. Note the output from the Nmap command.
    

    

    Notice that the user desktop has access to the FTP port and the HTTP port, but does not have ssh access. Nmap has proven that Iptables is configured to meet our stated security requirements.
    
    Admin (10.0.0.1) - TCP 22, 80
    User (10.0.0.2) - TCP 21, 80
    
    What if we need to add a new rule to our firewall?  Recall that the iptables firewall is a chain of rules, each rule being a link in that chain. Also recall that we added a DROP ALL at the bottom of the chain.
    
    In the next steps, we will do work in a new terminal window. Leave the x-terminal windows and the simulated HTTP and FTP windows open.
    
19. Open another new terminal window, then type sudo iptables -A INPUT -s 10.0.0.2 -p tcp --dport 22 -j ACCEPT and press Enter.
    
    In theory, this should allow 10.0.0.2 access to SSH. Will this new rule work?
    
20. In the new terminal window, type sudo iptables -L and press Enter to view the current ruleset.
    

    

    The new rule was added at the bottom of the chain and rules are read from top to bottom. Your new rule will be blocked by the second rule (DROP any traffic form 10.0.0.0 destined for TCP 22) and by the last rule (DROP ALL). The simplest fix is to clear the firewall and rewrite the chain in the correct order.
    
21. At the prompt, type sudo iptables -F and press Enter to clear the firewall rules
    
    Note: The F stands for "flush".
    
22. At the prompt, type sudo iptables -L and press Enter to validate that the firewall is back to fully open.
    

    

23. On the Desktop, double-click the IPTables Rules text file to open it in Notepad.
    
24. In the Notepad window, add sudo iptables -A INPUT -s 10.0.0.2 -p tcp --dport 22 -j ACCEPT in the correct place to allow 10.0.0.2 access to SSH.
    
25. In the open text file, use CTRL-A to select all the rules, then CTRL-C to copy them.
    
26. In the newest terminal window, right-click and select Paste to paste all the rules at once, then press Enter add the rules.
    
27. At the prompt, type sudo iptables -L and press Enter to confirm your new ruleset.
    
    Both admin (10.0.0.1) and user (10.0.0.2) should be able to access SSH, but any other host on the 10.0.0.0 network will be blocked.
    
    Now for a tricky question. Given that we have a DROP ALL at the bottom of our chain, do we really need the DROP rules for SSH and FTP? The answer is no. The DROP ANY rule at the bottom will drop any packet not allowed above.
    
28. Using the IPTables Rules file, rewrite the ruleset to remove the unneeded DROP rules, then apply the cleaned-up ruleset by flushing the current ruleset, and using copy/paste to apply the new ruleset.
    
29. In the open x-terminal windows, use Nmap to test the latest firewall ruleset.
    
    Notice that 10.0.0.2 now has SSH access as well as 10.0.0.1.